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Abstract 

The  primary  purpose  of  a  network  is  to  provide  reaeh- 
ability  between  applieations  running  on  end  hosts.  In 
this  paper,  we  deseribe  how  to  eompute  the  reaehability 
a  network  provides  from  a  snapshot  of  the  eonfiguration 
state  from  eaeh  of  the  routers.  Our  primary  eontribution 
is  the  preeise  definition  of  the  potential  reachability  of  a 
network  and  a  substantial  simpliheation  of  the  problem 
through  a  unified  modeling  of  paeket  filters  and  routing 
protoeols.  In  the  end,  we  reduee  a  eomplex,  important 
practieal  problem  to  eomputing  the  transitive  elosure  to 
set  union  and  interseetion  operations  on  reaehability  set 
representations.  We  then  extend  our  algorithm  to  model 
the  influenee  of  paeket  transformations  (e.g.,  by  NATs  or 
ToS  remapping)  along  the  path.  Our  teehnique  for  statie 
analysis  of  network  reaehability  is  valuable  for  verifying 
the  intent  of  the  network  designer,  troubleshooting  reaeha¬ 
bility  problems,  and  performing  “what-if”  analysis  of  fail¬ 
ure  seenarios. 

Index  Terms — Routing,  Static  Configuration  Analysis. 

I.  Introduction 

While  the  ultimate  goal  of  networking  is  to  enable  eom- 
munieation  between  hosts  that  are  not  direetly  eonneeted, 
a  wide  variety  of  meehanisms  are  being  used  to  limit  the 
set  of  destinations  the  hosts  ean  reaeh.  For  example,  baek- 
bone  networks  may  provide  Virtual  Private  Network  ser- 
viees  to  eonneet  only  remote  offiees  belonging  to  the  same 
enterprise,  and  enterprise  networks  themselves  are  often 
segmented  into  departments  or  offiees  whose  hosfs  musf 
be  isolafed  for  business  or  seeurify  reasons.  Also,  due  fo 
a  eonfiguralion  or  design  misfake,  fwo  hosfs  may  nof  be 
able  fo  eommunieafe  under  eerfain  failure  seenarios,  even 
fhough  fhe  nefwork  remains  eonneeted;  knowing  when 
fhese  vulnerabilifies  exisf  is  erueial  fo  building  a  more  re¬ 
liable  nefwork. 
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Defermining  whaf  kinds  of  packefs  can  be  exchanged 
befween  fwo  hosfs  connected  fo  a  nefwork  is  a  difficulf 
and  crifical  problem  facing  nefwork  designers  and  opera¬ 
tors.  To  our  knowledge,  fhe  problem  is  largely  unexam¬ 
ined  in  fhe  nefworking  research  liferafure.  Solving  fhe 
problem  requires  knowing  far  more  fhan  fhe  nefwork’s 
topology  or  fhe  routing  profocols  if  uses.  For  example, 
despite  having  a  route  to  a  remote  end-poinf,  a  sender’s 
packefs  may  be  discarded  by  a  packef  filter  on  one  of  fhe 
links  in  fhe  pafh.  The  nefwork’s  packef  fibers,  routing 
policies,  and  packef  fransformafions  all  musf  be  faken  into 
accounf  fo  even  ask  fhe  simple  and  very  imporfanf  ques¬ 
tion  of  “can  fhese  fwo  hosfs  communicate?” 

This  paper  crystallizes  the  problem  of  calculating  the 
reachability  provided  by  a  network.  By  mapping  packet 
filters,  routing  information,  and  packet  transformations  to 
a  single  unified  model  of  reachability  we  have  defermined 
how  to  fransform  fhis  seemingly  infracfable  problem  into 
a  classical  graph  problem  fhaf  can  be  solved  wifh  polyno¬ 
mial  lime  algorilhms  such  as  Iransilive  closure.  This  is  fhe 
primary  confribufion  of  fhis  paper. 

A.  Advantages  of  Automated  Static  Analysis 

Currenlly,  fhe  common  pracfice  to  determine  if  pack- 
els  can  reach  from  one  poinl  in  a  nefwork  fo  anolher  is  fo 
use  tools  such  as  ping  and  traceroute  fo  send  probe 
Iraffic  fhaf  experimenlally  lesl  whelher  reachabilily  exisls. 
In  conlrasl,  we  have  developed  a  static-analysis  approach 
fhaf  can  be  applied  even  if  only  a  description  of  fhe  nel- 
work  is  available.  Sialic  analysis  has  many  advanlages 
over  ping  and  traceroute,  including: 

•  The  abilily  to  delermine  a  descriplion  of  fhe  sel  of 
packefs  fhaf  could  fraverse  fhe  nefwork  from  a  given 
slarling  poinl  fo  a  given  ending  poinl,  whereas  exper- 
imenfal  techniques  can  only  check  fhe  reachability  of 
fhe  specific  probe  Iraffic  Ihey  send. 

•  The  ability  to  calculate  fhe  sel  of  routers  and  hosfs 
fhaf  a  given  packef  could  potentially  reach,  whereas 
ping  and  traceroute  can  only  check  reachabil¬ 
ily  along  fhe  pafh  currenlly  selecled  by  fhe  routing 
protocols. 

•  The  ability  to  evaluate  fhe  reachability  of  a  nel- 
work  during  ils  design  phase — before  fhe  nefwork 
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has  been  deployed  or  a  problem  has  arisen.  Network 
operators  can  perform  our  static  analysis  using  only 
the  configuration  files  used  fo  program  fhe  nefwork’s 
roufers,  and  fhese  files  are  readily  available  fo  fhem. 

•  The  abilify  fo  verify  whefher  fhe  reachabilify  a  nef- 
work  acfually  provides  mafches  fhe  designer’s  in- 
fenf.  Sfafic  analysis  can  verify  fhaf  Virfual  Private 
Nefworks  are,  in  facl,  isolafed  from  ofher  Iraffic.  If 
can  also  be  used  fo  conducf  “whal-if”  analysis — 
predicting  fhe  effecls  of  equipmenf  failures  and 
planned  maintenance  on  fhe  communicafion  befween 
end  hosfs.  While  synfax  verificalion  of  router  config¬ 
uration  has  been  evaluafed  [3],  [8],  fhere  is  little  un- 
dersfanding  of  fhe  power  and  limifafion  of  semanfic 
verificalion  based  on  sfafic  analysis. 

Manually  calculafing  fhe  sialic  reachabilify  of  a  nel- 
work  is  often  impractical,  as  dala  show  lhal  campus,  en¬ 
terprise,  and  backbone  nefworks  vary  in  size  from  5  fo  500 
routers,  wilh  fhe  largesl  nefworks  having  on  fhe  order  of 
1,000  routers,  and  fhaf  real  nefworks  use  a  wide  variety 
of  mechanisms  fo  conlrol  fhe  reachabilify  Ihey  provide. 
A  survey  of  31  production  nefworks  [10],  including  ex¬ 
amples  of  bolh  carrier  backbone  and  enterprise  nefworks, 
found  lhal  10  oul  of  fhe  27  enferprise  nefworks  had  packel 
filters  applied  fo  Iheir  internal  links.  Several  of  fhe  nel- 
works  deliberalely  prevenfed  some  hosfs  from  reaching 
olhers  by  preventing  fhe  dislribulion  of  rouling  informa¬ 
tion  needed  fo  direcl  packels  befween  fhe  hosfs.  Furlher 
complicaling  fhe  queslion  of  a  nefwork’s  reachability  is 
fhe  use  of  mechanisms  fhaf  acfually  transform  packels  as 
Ihey  Iravel  across  fhe  nelwork.  For  example,  Nelwork 
Address  Translalors  (NATs)  [15]  lhal  change  a  packel’s 
source  and  desfinafion  address  were  found  in  fhe  inte¬ 
rior  of  10  of  fhe  31  nefworks.  Undersfanding  fhe  reach¬ 
ability  “malrix”  created  by  a  nelwork  requires  a  frame¬ 
work  for  reasoning  aboul  fhe  effecls  of  all  fhese  differenl 
mechanisms — ^packel  filters,  routing  policy,  and  packel 
Iransformalions — af  fhe  same  time. 

B.  Our  Contributions 

First,  we  formulate  the  problem  of  computing  the  reach¬ 
ability  of  a  network  and  argue  for  the  importance  of  craft¬ 
ing  good  solutions.  We  focus  on  the  value  of  computing 
reachability  through  static  analysis.  We  rigorously  define 
fhe  reachability  of  a  nelwork,  and  we  define  expressions 
for  upper  and  lower  bounds  on  fhe  reachabilify. 

Second,  we  describe  a  tractable  framework  for  jointly 
reasoning  about  how  packet  filters,  routing,  and  packet 
transformations  affect  the  reachability  lhal  a  nelwork  pro¬ 
vides.  Bringing  logelher  fhese  fhree  very  differenl  lypes  of 


mechanisms  is  crilical  fo  accurately  compuling  fhe  reach¬ 
ability  of  a  nelwork. 

Third,  we  presenf  an  algorithm  for  the  static  analysis  of 
reachability  for  IP  nefworks  and  explain  how  fhe  nelwork 
model  can  be  populaled  by  sialic  analysis  of  fhe  nelwork’s 
router  configuration  files. 

C.  Structure  of  the  Paper 

In  Section  II,  we  presenf  a  brief  overview  of  fhe  mosl 
relevanl  aspecls  of  how  roufers  operate  and  are  config¬ 
ured.  We  Ihen  formally  describe  our  framework  for  ana¬ 
lyzing  a  nelwork’s  reachabilify  in  Seclion  III,  beginning 
our  analysis  by  focusing  on  packel  filters.  We  presenf 
our  algorilhm  for  calculating  reachability  in  Section  IV. 
In  Seclion  V  we  show  how  fo  map  routing  information 
fo  packel  filters  and  how  Ihis  model  of  rouling  is  popu- 
lafed  by  analyzing  fhe  rouler  configuration  files.  In  Sec¬ 
tion  VI  we  describe  how  packel  Iransforming  mechanisms 
are  handled.  Seclion  VII  discusses  fhe  applications  and 
limifafions  of  our  approach.  After  a  brief  overview  of  re- 
laled  work  in  Section  VIII,  fhe  paper  concludes  in  Sec¬ 
tion  IX  wilh  a  summary  of  our  conlribulions. 

II.  Background  on  Reachability 
Configuration 

In  addition  fo  forming  fhe  physical  fopology  of  roufers 
and  links,  nelwork  operators  musl  configure  fhe  protocols 
and  mechanisms  lhal  colleclively  determine  which  hosfs 
can  communicale.  Today’s  roufers  offer  a  weallh  of  con- 
figuralion  options  for  enabling  and  luning  packel  filters, 
routing  protocols,  and  packel  Iransformalions.  Our  analy¬ 
sis  lechniques  operate  on  a  snapshol  of  fhe  configuration 
slate  for  each  of  fhe  roufers  in  fhe  nelwork,  as  recorded  in 
a  configuration  file.  In  well-managed  nefworks,  fhese  files 
are  roufinely  caplured  and  archived  for  backup  purposes, 
and  are  available  fo  nelwork  operalors. 

To  make  our  discussion  of  fhe  differenl  reachability 
configurafion  oplions  more  concrele,  we  focus  on  fhe  ex¬ 
ample  enferprise  nelwork  in  Figure  1.  The  nelwork  has 
five  roufers  R1  fo  R5  (depicted  as  solid  reclangles)  con- 
necled  via  physical  links  (depicted  as  solid  lines)  lhal  fer- 
minale  al  interfaces  (depicted  as  small  circles).  R1  and  R3 
are  remote  sales  offices  connecled  direclly  fo  fhe  cenlral 
office  where  R2,  R4,  and  R5  reside.  R6  represenls  fhe  ex¬ 
ternal  router  in  fhe  service  provider’s  nelwork  where  fhe 
enferprise  connecls  fo  fhe  Inlernel. 

Each  sales  office  has  Iwo  subnels,  A  and  B.  Crilical  ac- 
counling  applicalions  are  run  by  hosfs  connected  to  subnel 
A,  and  general  purpose  computers  are  connected  to  subnel 
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B3 


O  =  interface 
I —  =  subnet 

- =  primary  link 

- =  backup  link 

R6  =  external  router 

.  link  to  Internet 

h—  =  packet  filter 


Fig.  1.  An  example  enterprise  network  with  fi  ve  routers 


ACL 

Definition 

ACL  1 

permit  tcp  Al  A5  port  eq  1433 
deny  tcp  any  any  port  eq  1433 

ACL  2 

deny  77  any  any 

ACL  3 

permit  tcp  A3  A5  port  eq  1433 
deny  tcp  any  any  port  eq  1433 
deny  ip  any  224.0.0.0/8 

ACL  4 

deny  55  any  any 

TABLE  I 

Four  packet  filters  instantiated  in  Figure  1 


B.  Hosts  on  subnets  A1  and  A3  must  be  able  to  eommu- 
nieate  with  eorporate  servers  in  subnet  A5,  but  the  net¬ 
work’s  poliey  is  to  prevent  any  other  hosts  from  eommu- 
nieating  with  the  servers  on  A5  to  reduee  the  ehanees  of  a 
server  eompromise.  To  make  the  network  more  resilient  to 
link  failures,  the  operators  are  planning  to  add  two  baekup 
links  (shown  with  dashed  lines).  In  Seetion  4  and  beyond, 
we  show  that  our  reaehability  analysis  teehnique  ean  pre¬ 
diet  the  effeet  of  adding  these  links  and  prevent  a  design 
error  that  would  violate  the  network’s  goals. 

A.  Packet  Filters 

The  simplest  way  to  eontrol  reaehability  is  to  eonfigure 
an  interfaee  to  filter  unwanted  paekets  in  the  data  plane. 
Today’s  routers  allow  operators  to  filter  paekets  based  on  a 
eombination  of  fields  in  fhe  paekef  header,  sueh  as  souree 
and  desfinafion  IP  addresses,  fype-of-serviee  (ToS)  bifs, 
porf  numbers,  and  profoeol.  Eaeh  paekef  filfer  eonsisfs 
of  a  sequenee  of  elauses  fhaf  fhaf  permif  or  deny  eerfain 
paekef s  based  on  fheir  header  fields.  A  filler  ean  be  in- 
slanlialed  on  a  parlieular  inlerfaee  lo  filler  ineoming  or 
oulgoing  paekels.  An  inlerfaee  may  have  differenl  fillers 
for  ineoming  and  oulgoing  paekels,  and  differenl  inler- 
faees  may  be  assigned  differenl  fillers. 

Table  I  shows  four  aeeess-eonlrol  lisl  (ACL)  speeifi- 
ealions,  defined  in  fhe  Ciseo  lOS  language;  paekels  nol 
malehing  any  elause  are  permilfed  by  defaull.  Figure  1 
shows  where  Ihese  ACLs  are  used  lo  filler  oulgoing  paek¬ 
els  on  four  inlerfaees.  ACLl  permils  TCP  paekels  des- 
lined  lo  Mierosofl  SQL  servers  (porl  1433)  in  subnel  A5 
from  hosls  in  Al,  bul  denies  Ihem  from  any  olher  sub¬ 


nel;  inslanlialing  Ihis  paekel  filler  on  Ihe  link  from  R1  lo 
R5  is  meanl  lo  prevenl  olher  subnels  from  aeeessing  Ihe 
eorporale  servers  on  subnel  A5.  ACL2  drops  all  Sun  ND 
proloeol  paekels  (proloeol  77),  whieh  were  impliealed  in 
an  earlier  allaek  on  Ciseo  routers.  Like  ACLl,  ACL3  per¬ 
mils  TCP  paekels  lo  Ihe  Mierosofl  SQL  server  (porl  1433) 
from  hosls  in  A3,  bul  denies  Ihem  from  any  olher  subnel. 
ACL  3  also  prevenls  mullieasl  paekels  (in  Ihe  IP  address 
range  224.0.0.0/8)  from  leaving  Ihe  ofliee  eonlaining  R3. 
ACL4  drops  all  Mobile  IP  paekels  (proloeol  55),  which 
were  also  implicated  in  an  earlier  attack  on  Cisco  routers. 

B.  Routing  Protocols 

Rouling  protocols  influence  reachability  by  conlrolling 
Ihe  conslruclion  of  Ihe  forwarding  fable  on  each  router. 
Conceplually,  a  route  is  a  nelwork  address  (e.g.,  an  IP  ad¬ 
dress  and  a  mask  lenglh,  such  as  10.0.0.0/8)  along  wilh 
addilional  attributes  (e.g.,  numerical  weighls,  AS  palhs, 
or  nexl-hop  IP  address)  lhal  a  router  can  use  to  determine 
which  oulgoing  link  to  use  to  reach  lhal  subnel.  A  router 
can  learn  a  route  in  several  ways.  Firsl,  a  router  knows 
locally  how  to  reach  all  direclly-connecled  subnels — Ihe 
incidenl  links  Ihemselves.  Second,  Ihe  router  may  be  con¬ 
figured  wilh  sialic  routes  lhal  map  a  deslinalion  subnel 
direclly  to  one  or  more  oulgoing  interfaces.  Third,  Ihe 
router  may  learn  Ihe  informalion  dynamically  Ihrough  a 
rouling  protocol,  such  as  OSPF  [11],  IS-IS  [4],  BGP  [13], 
RIP  [9],  or  EIGRP  [17]. 

To  conlrol  Ihe  sharing  of  rouling  informalion,  each  in- 
slance  of  a  rouling  protocol  runs  as  a  separate  routing  pro¬ 
cess  on  Ihe  router.  Jusl  as  wilh  operaling  system  process 
boundaries,  by  defaull  no  informalion  is  exchanged  be- 
Iween  Ihese  enlilies,  and  Ihey  operate  completely  inde- 
pendenlly.  Each  rouling  process  has  a  Routing  Informa¬ 
tion  Base  (RIB)  lhal  stores  Ihe  routes  on  which  il  operates, 
similar  to  Ihe  virlual  memory  space  of  a  process.  To  sim¬ 
plify  Ihe  discussion,  we  consider  Ihe  direclly-connecled 
subnels  and  sialic  routes  as  belonging  to  a  single  process 
lhal  creates  a  local  RIB.  A  router  can  run  mulliple  rouling 
processes  simullaneously,  including  mulliple  inslances  of 
Ihe  same  rouling  protocol.  For  example.  Figure  2  illus- 
Irales  Ihe  rouling  processes  (as  represented  by  Iheir  RIBs) 
for  Ihe  nelwork  in  Figure  1,  after  Ihe  Iwo  backup  links 
have  been  added.  Router  2  runs  Iwo  inslances  of  OSPF 
and  one  inslance  of  BGP,  and  has  a  local  RIB. 

Rouling  processes  do  nol  exchange  informalion  unless 
specifically  configured  to  do  so.  The  dashed  lines  in  Fig¬ 
ure  2  indicate  adjacencies  belween  rouling  processes  on 
differenl  routers,  or  route  redislribulion  belween  RIBs  on 
Ihe  same  router.  For  example,  router  2  exchanges  rouling 
informalion  via  OSPF  wilh  router  1  and  router  3;  routes 
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from  the  OSPF  RIB  are  redistributed  to  BGP  and  adver¬ 
tised  via  external  BGP  (EBGP)  to  router  6.  The  other  in¬ 
stance  of  OSPF  on  router  2  does  the  same  for  routers  4 
and  5.  The  routes  from  router  2’s  local  RIB  are  also  redis¬ 
tributed  to  the  BGP  RIB,  and  onward  to  router  6.  Thus, 
router  2  takes  responsibility  for  ensuring  that  the  subnets 
in  the  enterprise  network  are  reachable  from  the  rest  of  the 
Internet  via  router  6. 

Rather  than  exchanging  routes  to  every  subnet,  the  dis¬ 
tribution  of  routes  is  governed  by  routing  policies.  A  pol¬ 
icy  can  be  thought  of  as  an  annotation  on  the  dashed  line 
denoting  the  exchange  (e.g.,  routing  policies  1  (RPl)  and 
2  (RP2)  in  Figure  2).  For  example,  router  2  could  be  con¬ 
figured  to  filter  the  route  to  subnet  A5  (i.e.,  the  sensitive 
corporate  servers)  when  distributing  routes  via  eBGP  to 
router  6.  Modern  routers  have  rich  languages  for  specify¬ 
ing  routing  policies,  including  the  ability  to  select  which 
routes  should  be  imported  or  exported  based  on  any  of  the 
attributes  associated  with  the  route  (e.g.,  the  subnet  or  the 
AS  path).  Routing  policies  can  also  alter  the  attributes  of 
the  routes  they  accept  (e.g.,  changing  metrics  or  adding  an 
AS  number  onto  an  AS  path). 

Upon  receiving  multiple  routes  for  the  same  subnet,  the 
routing  process  must  select  a  single  best  route.  The  se¬ 
lection  of  the  best  route  depends  on  the  route  attributes 
and  logic  defined  for  fhe  particular  profocol.  For  exam¬ 
ple,  BGP  has  a  complex  mulfi-sfage  process  for  identi¬ 
fying  fhe  besf  roufe  [16],  whereas  OSPF  selecfs  fhe  pafh 
wifh  fhe  smallesf  cosf  as  fhe  sum  of  fhe  link  weighfs  [11]. 
If  multiple  RIBs  on  fhe  same  router  have  a  besf  route  for 
fhe  same  subnef,  fhe  router  musf  determine  which  roufing 
process  should  confrol  fhe  enfry  in  fhe  forwarding  fable. 
For  example,  fhe  router  may  impose  a  sfafic  ranking  on 
fhe  roufing  processes  (e.g.,  giving  fhe  local  RIB  priorify 
over  BGP-learned  routes). 

C.  Packet  Transformations 

The  roufers  make  packef  tillering  and  forwarding  deci¬ 
sions  based  on  fields  in  fhe  header  of  each  packef.  How¬ 
ever,  Ihese  header  fields  may  change  as  a  packef  flows 
Ihrough  fhe  nelwork.  For  example,  fhe  nelwork  operalor 
may  configure  rouler  R2  in  Figure  1  fo  resel  fhe  ToS  bifs 
of  incoming  packefs  from  R6.  If  fhe  enferprise  nelwork 
assigns  packefs  fo  differenl  queues  based  on  fhe  ToS  bifs, 
selling  fhe  ToS  bifs  fo  a  defaull  value  would  ensure  lhal 
Iraffic  coming  from  fhe  Inlernel  does  nol  enter  fhe  same 
queue  as  high-priorify  infernal  Iraffic.  Similarly,  R2  could 
be  configured  fo  map  fhe  source  IP  addresses  of  pack- 
els  leaving  fhe  nelwork  via  R6,  in  order  fo  use  private 
IP  addresses  inside  fhe  enterprise  and  public  addresses 
in  communicaling  wifh  fhe  external  Inlemef.  Alfhough 


Fig.  2.  Interactions  of  routing  processes  in  the  example  network  in 
Figure  1.  Each  routing  process  is  depicted  by  the  RIB  that  stores  its 
routes.  Dashed  lines  indicate  the  import,  export,  and  redistribution 
of  routes.  Interfaces  are  marked  with  identifi  ers  and  the  solid  lines 
between  interfaces  are  the  physical  links. 

slaleful  Nelwork  Address  Translator  (NAT)  and  firewall 
devices  may  Iransform  or  rale-limif  packefs  in  complex 
ways,  fhe  funclionalify  supported  (and  enabled)  direclly  in 
fhe  roufers  is  often  much  simpler.  In  our  analysis,  we  fo¬ 
cus  on  Ihis  simpler  form  of  slafically-configured  Iransfor- 
malions  and  how  Ihey  influence  fhe  reachabilily  belween 
end  hosls. 

in.  Problem  Formulation 

In  Ibis  seclion,  we  formulaic  fhe  reachabilily  analysis 
problem.  We  firsl  describe  a  graph  model  for  computing 
reachabilily  which  allows  joinl  reasoning  of  fhe  effecls  of 
packef  fillers  and  routing  prolocols.  We  Ihen  formally  de¬ 
fine  fhe  reachabilily  melrics  largefed  by  our  analysis.  In 
parlicular,  we  inlroduce  fhe  concepl  of  fhe  inslanfaneous 
reachabilily  provided  by  a  nelwork,  and  explain  why  if  is 
useful  fo  develop  bounds  on  fhe  reachabilily  provided  by 
fhe  nelwork.  We  end  Ihis  section  wifh  an  example  illus- 
fraling  fhe  pofenlial  value  of  being  able  to  compufe  fhe 
reachabilily  bounds. 

A.  A  Unifying  Model 

The  crux  of  determining  fhe  reachabilily  of  a  nelwork  is 
finding  a  way  fo  unify  Iwo  very  differenl  views  of  fhe  nef- 
work.  The  firsl  is  fhe  graph  of  roufers  and  links,  illuslraled 
in  Figure  1,  where  verlices  are  routers  and  edges  are  phys¬ 
ical  links  lhal  may  have  packef  filters  applied  on  Ihem. 
The  second  is  fhe  routing  process  graph,  illuslraled  in  Fig¬ 
ure  2,  where  verlices  are  routing  processes  and  edges  are 
adjacencies  lhal  implemenl  routing  policy.  Unifying  Ihese 
views  requires  combining  fhe  policies  governing  redislri- 
bufion  of  routes  wifh  fhe  packef  filters  governing  which 
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packets  can  traverse  a  link.  This  unified  framework  un¬ 
derlies  our  reachability  analysis,  and  will  be  extended  to 
address  packet  transforms  in  Section  VI. 

We  define  fhe  reachabilify  analysis  problem  by  extend¬ 
ing  fhe  graph  of  links  and  roufers  -  annofafing  fhe  edges 
of  fhe  graph  more  elaborately.  Formally,  we  define  fhe 
graph  G  =  (V,  E,  E)  where  V  is  fhe  sef  of  roufers,  E  is 
fhe  sef  of  direcfed  edges  defining  fhe  connecfivify  befween 
fhe  roufers,  and  ,7^  is  a  labeling  funcfion  fhaf  annofafes  fhe 
edges  in  E.  As  fhe  graph  is  direcfed,  fwo  roufers  direcfly 
connecfed  by  a  physical  link  will  have  fwo  edges  befween 
fhem,  one  in  each  direcfion.  For  each  edge  <  u,v  >E  E, 
Pu,v  £  ^  represenfs  fhe  policies  governing  fhe  flow  of 
packefs  from  tt  fo 

The  challenge  in  building  fhis  graph  model  G  from  fhe 
sialic  analysis  of  configuration  dala  is  fhaf  Ey^^y  cannol  be 
a  simple  melric  like  an  integer  weighl.  If  musl  embody  fhe 
effecls  of  fhe  complex  collection  of  packel  fillers  and  roul- 
ing  prolocols  used  by  fhe  nefwork,  bul  slill  be  amenable 
lo  efficienf  arilhmelic-like  manipulations.  We  define  Ey^y 
fo  be  the  set  of  packets  that  the  network  is  able  to  carry 
from  u  to  V.  Ey^y  can  also  be  represenled  by  a  packel  filter 
fy^y  conlaining  predicates  fhaf  lesl  properties  of  packel  p, 
reluming  frue  if  fhe  packel  should  be  in  fhe  sef  Ey^y.  De¬ 
termining  which  packefs  can  flow  from  rouler  u  fo  router 
V  lo  router  w  can  Ihen  be  wrillen  simply  as  Ey^y  fl  Ey^yj  or 

fu,v  ^  fv,w 

The  advanlage  of  representing  fhe  reachabilify  problem 
as  a  graph  G  =  (V,  E^  E)  is  fhaf  if  exposes  fhe  similarily 
befween  our  problem  and  fhe  class  of  well-known  prob¬ 
lems  such  as  Iransilive  closure  and  shorlesl-palh  compu- 
lalion,  allowing  us  lo  use  Iheir  efficienf  solutions  [1],  [6] 
when  computing  fhe  reachabilify  of  a  nefwork. 

Packel  fillers  defined  by  fhe  nefwork  can  be  easily  rep¬ 
resented  in  fhe  graph  model  G.  Nefwork  configuralion 
files  define  a  packel  filler  /  as  a  series  of  predicates  over 
packel  elemenfs.  For  example,  /  may  be  “p.src_addr  E 
128.2/16  A  p.desl_porl  7/  135”,  which  accepfs  all  packefs 
from  fhe  128.2/16  subnel  excepl  for  Ihose  going  lo  porl 
135.  By  parsing  fhe  configuralion  files  we  can  exlracl  fhe 
predicale  /  applied  lo  fhe  link  from  router  u  lo  router  v, 
and  annolafe  fhe  edge  <  u,v  >E  E  wilh  fhe  sef  of  pack- 
els  fhaf  /  accepfs,  i.e.,  Ey^y  =  {p  |  /(p)  =  1}. 

The  inluilion  behind  our  framework  for  joinlly  mod¬ 
eling  rouling  and  packel  filtering  is  fhaf  rouling  can  be 
Ihoughl  of  as  a  kind  of  dynamically  conslrucled  packel  fil¬ 
ter.  If  rouling  process  on  router  A  holds  a  route  for  subnel 

^We  believe  our  framework  can  be  trivially  extended  to  handle  mul¬ 
tiple  physical  links  between  u  and  v,  but  for  the  remainder  of  this 
paper  we  assume  there  is  at  most  one  physical  link  between  each  pair 
of  routers. 


d  wilh  a  nexl  hop  of  interface  i,  if  means  A  mighl  forward 
packefs  lo  d  oul  fhaf  inlerface.  Therefore,  we  can  Ireal  fhis 
route  as  if  if  were  a  permil  clause  for  d  in  fhe  packel  filter 
on  interface  i.  Inversely,  if  router  A  holds  no  routes  lhal 
could  possibly  send  packefs  lo  destination  d  oul  interface 
i,  Ihen  we  can  add  a  clause  lo  Ihe  packel  filter  on  interface 
i  lo  drop  all  packels  headed  lo  destination  d. 

B.  Formal  Definitions  of  Reachability  Metrics 

We  describe  Ihe  reachabilify  befween  Iwo  poinls  in  a 
nefwork  in  terms  of  the  the  subset  of  packets  (from  the 
universe  of  all  IP  packets)  that  the  network  will  carry  be¬ 
tween  those  points.  Thus,  reachability  from  router  i  to 
router  j  is  given  by  the  subset  of  packets  that  the  network 
will  carry  from  i  to  j  and  is  denoted  as  Rij.  Note  that 
it  is  common  for  to  include  packets  that  are  neither 
sourced  by  a  host  connected  to  i  nor  destined  to  a  host 
connected  to  j  —  this  must  be  true  if  routers  are  to  for¬ 
ward  packets  along  multiple  hops. 

Clearly,  the  action  of  the  network’s  routing  protocols 
will  directly  influence  Rij,  for  if  router  i  has  no  routes 
for  destination  d,  then  packets  to  d  cannot  be  elements  of 
Rij,  since  i  will  be  dropping  those  packets.  More  gen¬ 
erally,  the  network  is  continually  affected  by  events  such 
as  link  failures  and  changes  in  routing  advertisements  re¬ 
ceived  from  peer  networks.  Through  the  action  of  routing 
protocols  and  other  mechanisms,  each  router  will  populate 
its  Forwarding  Information  Base  (FIB)  with  information 
determining  the  interface(s)  out  which  each  packet  should 
be  sent.  We  define  the  collective  contents  of  the  FIB  on 
each  router  in  the  network  to  be  the  network’s /orwardmg 
state,  denoted  by  s.  We  also  define  S  to  represent  the  set 
of  all  possible  forwarding  states  that  the  network  can  pos¬ 
sibly  enter,  as  it  responds  to  any  imaginable  set  of  external 
advertisements,  link  failures,  etc.^ 

1 )  Instantaneous  reachability:  The  Reachability  pro¬ 
vided  by  the  network  will  change  as  a  function  of  the  net¬ 
work’s  forwarding  state  s,  which  may  change  from  instant 
to  instant  as  the  network  responds  to  events.  Therefore, 
our  first  step  is  to  precisely  define  the  reachability  pro¬ 
vided  by  a  network  at  a  single  instant  in  time,  assum¬ 
ing  that  the  forwarding  state  s  in  effect  at  that  instant  is 
known. 

The  influence  of  any  given  forwarding  state  s  E  5  on 
the  reachability  in  the  network  can  be  accounted  for  by 
incorporating  additional  packet  filters  into  Ey^y.  In  doing 
so,  the  policy  annotation  at  each  edge  in  the  reachability 

^When  conducting  a  particular  analysis  of  a  particular  network,  the 
human  conducting  the  analysis  might  want  to  restrict  S  to  the  forward¬ 
ing  states  reachable  under  a  more  restricted  set  of  events,  such  as  ‘ho 
more  than  one  link  or  router  will  fail  at  a  time.” 
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analysis  graph  becomes  a  function  of  s,  written  as  (s)  ■ 
Assume  Iu{s,d)  to  be  a  function  that  returns  the  set  of 
next  hop  routers  to  which  router  u  will  forward  packets 
destined  to  IP  subnet  d  while  the  network  is  in  forward¬ 
ing  state  s.  Fy^^y{s)  can  then  be  formally  defined  as  an 
extension  to  the  statically  configured  packef  filters  F^^v 

Fu,v{s)  =  Fu^y  n  {p  I  p.dst_addr  e  {d  |  n  £  4(s,  d)}} 

(1) 

Let  V{i,j)  be  the  set  of  all  loop-free  paths  from  i  to  j  in 
the  network’s  physical  topology.  Using  all  these  concepts, 
we  can  now  precisely  define  fhe  instantaneous  reachabil¬ 
ity  from  i  to  j  provided  by  the  network  while  at  routing 
state  s  as: 

~  u  n  ^u,v{s)  (2) 

7re'P(i,j)  <u,v>e'K 

2)  Bounding  the  Instantaneous  Reachability:  In  the¬ 
ory,  it  should  be  possible  to  compute  exactly  what  for¬ 
warding  state,  and  thus  what  reachability,  a  network  pro¬ 
vides  at  any  instant  in  time.  After  all,  each  router  in 
the  network  is  a  computing  device  with  its  behavior  pro¬ 
grammed  and  controlled  by  configuration  commands.  Un¬ 
fortunately,  computing  the  instantaneous  reachability  of 
a  network  requires  knowing  the  current  topology  (e.g., 
which  links  and  routers  are  up  or  down)  and  the  exact  in¬ 
formation  given  to  the  network  by  neighboring  domains 
in  the  outside  world  (e.g.,  the  routing  updates  from  BGP 
peers).  Dynamic  information  of  this  kind  might  not  be 
available  (e.g.,  the  network  is  not  deployed  yet),  and  its 
use  makes  the  instantaneous  reachability  results  depend 
heavily  on  the  exact  inputs  used.  For  example,  if  the  ex¬ 
act  set  of  routes  offered  by  external  peers  to  the  network 
under  analysis  is  known,  then  the  reachability  to  those 
destinations  at  that  instant  could  be  calculated.  However, 
the  calculated  reachability  is  applicable  only  in  situations 
where  the  external  peers  offer  exactly  those  routes,  which 
severely  limits  the  usefulness  of  the  reachability  analysis. 

Further,  computing  the  instantaneous  reachability  of  a 
network  requires  knowing  not  only  the  configuration  state 
of  each  router,  it  requires  the  tedious  and  error-prone  cod¬ 
ing  of  an  exact  bug-for-bug  emulation  of  the  decision 
logic  used  by  the  particular  version  of  the  software  run¬ 
ning  on  each  router.  (More  than  200  different  software 
versions  were  used  by  the  routers  in  the  31  production 
networks  we  recently  examined  in  our  study  of  IP  routing 
design  [10].)  While  the  routing  protocols  are  defined  by 
sfandards,  each  vendor  has  implemented  them  differently. 
For  example,  the  Border  Gateway  Protocol  (BGP)  [13] 
defines  a  seven-sfep  process  for  selecting  a  route  to  a  des¬ 


tination,  but  Cisco  has  added  several  more  decision  steps 
in  their  implementation  [16]. 

The  goal  of  most  network  designers  is  to  ensure  that 
the  network’s  behavior  remains  within  some  “acceptable 
operating  region”  under  reasonable  predictions  of  how 
routers/links  might  fail  or  outside  events  might  change. 
This  means  that  more  useful  than  calculating  the  instanta¬ 
neous  reachability  of  a  network  is  the  ability  to  calculate 
bounds  on  the  reachability  provided  by  the  network.  That 
is,  given  some  set  of  reasonable  events,  predict  the  “op¬ 
erating  region”  of  the  network.  We  do  this  by  defining 
two  key  bounds:  the  upper  bound  on  reachability,  which 
is  the  largest  set  of  packets  the  network  will  ever  deliver 
between  two  points,  and  the  lower  bound  on  reachability, 
which  is  the  largest  set  of  packets  the  network  will  always 
deliver  between  two  points. 

Reachability  upper  bound:  Formally,  we  define  the 
upper  bound  of  the  reachability  over  all  routing  states  as 
follows: 

=  U  (3) 

sES 

Conceptually,  captures  the  notion  that  as  external 
events  change,  the  path  the  network  chooses  for  a  packet 
moving  from  i  to  j  will  change  as  a  function  of  the  route 
selection  logic  and  the  external  routing  advertisements. 
Therefore,  taking  the  union  of  the  set  of  packets  that  can 
traverse  each  path  from  i  to  j  under  each  state  s  produces 
a  superset  of  the  instantaneous  reachability  —  that  is, 
is  the  set  of  packets  that  could  potentially  reach  from  i  to  j 
if  the  routing  decisions  were  made  appropriately.  The  set 
negation  of  R^j  is  particularly  useful,  as  a  packet  appear¬ 
ing  in  this  complement  of  Rf^  cannot  ever  reach  from  i 
to  j.  Essentially,  the  packet  is  blocked  along  every  pos¬ 
sible  path.  This  allows  us  to  verify  whether  the  network 
enforces  security  policies  intended  to  isolate  traffic. 

Reachability  lower  bound:  Formally,  we  define  fhe 
lower  bound  for  reachability  as  follows: 

=  n  (4) 

sES 

Conceptually,  captures  the  notion  that  a  packet  per¬ 
mitted  to  reach  between  i  and  j  under  all  possible  for¬ 
warding  states  s  E  S  will  always  be  able  to  get  from  i  to 
j.  For  the  lower  bound  to  give  useful  information  about 
the  network’s  routing  design,  we  first  need  to  restrict  S  to 
those  routing  states  induced  from  a  set  of  network  events 
targeted  by  the  analysis.  In  particular,  S  should  not  in¬ 
clude  any  forwarding  states  corresponding  to  failure  sce¬ 
narios  that  would  physically  disconnect  i  and  j  (or  Rf^ 
will  be  trivially  0). 
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Rfj  is  useful  to  network  designers  beeause  the  net¬ 
work’s  routing  design  guarantees  that  paekets  appearing 
in  this  set  will  be  deliverable  between  i  and  j  as  long  as 
the  network  is  not  physieally  partitioned.  Designers  ean 
then  verify  that  traffie  requiring  robustness  appears  in  this 
set. 

3)  Approximating  the  Reachability  Bounds:  As  dis- 
eussed  earlier,  it  is  diffieult  and  error-prone  to  preeisely 
model  the  route  seleetion  logie  and  external  routing  ad¬ 
vertisements  under  all  events.  Further,  the  size  of  S  is 
enormous,  even  for  small  networks.  Combined  together, 
these  two  faetors  make  it  seem  impossible  to  aeeurately 
eompute  S  or  Fu^v{s)  for  every  s.  Therefore,  we  eannot 
use  equation  (3)  to  exaetly  eompute  or  equation  (4) 
to  eompute  Rf^.  Instead,  we  must  develop  estimators  for 
RYj  and  Rf'j. 

We  denote  estimators  to  and  as  RY,  and  R^,, 
respeetively.  Ideally,  these  estimators  should  be  looser 
bounds,  that  is: 

Rij  C  C  Rij{s)  C  R-j  C  R-j 

as  this  property  maximizes  the  utility  of  Rfj  and  R^j  in 
verifying  network  properties.  For  example,  a  Rf^  that  is 
looser  than  Rfj  may  ineorreetly  warn  an  operator  that  the 
paekets  in  Rfj  —  Rfj  eould  violate  the  network’s  traffie 
isolation  polieies,  but  in  this  situation  a  false-positive  is 
mueh  better  than  a  false-negative. 

Even  simple  estimators  to  RY,  and  RR  still  have  value 
in  predieting  network  properties.  For  example,  we  ean  ob¬ 
tain  simple  estimators  by  ignoring  the  effeet  of  the  rout¬ 
ing  protoeols  entirely,  so  that  Fu^v  models  only  the  statie 
paeket  filters  defined  on  edge  <  tt,  u  >.  The  upper  bound 
ean  fhen  be  ealeulafed  by  finding  fhe  sef  of  paekefs  fhaf  af 
leasf  one  pafh  fhrough  fhe  nefwork  will  allow  fo  pass  from 
ito  j,  sinee  fhere  eould  be  some  routing  slate  lhal  ehooses 
Ihis  pafh  for  fhe  paekefs. 

Tre'Pftif)  <u,v>e'K 

Similarly,  fhe  lower  bound  ean  be  ealeulafed  by  finding 
fhe  sef  of  paekefs  lhal  all  palhs  from  i  fo  j  allow  lo  pass, 
sinee,  so  long  as  i  and  j  are  nof  partitioned,  al  teas!  one  of 
Ihese  palhs  will  exisl  and  could  be  ehosen  by  fhe  routing 
proloeols. 

Tre'Pftif)  <u,v>e'K 


If  is  slraighlforward  lo  prove  lhal  Ihis  eslimalor  Rf^  D 
RY:  [19].  It  ean  be  shown  that  Rh^  C  RF  if  we  ean  as- 
sume  that  when  only  one  path  exists  from  i  to  j  the  routing 
design  of  network  is  sueh  that  the  path  will  be  used.^ 

In  Seetion  V,  we  deseribe  an  approaeh  to  approximat¬ 
ing  the  effeet  of  the  routing  protoeols  on  reaehability  that 
yields  tighter  estimators.  Our  expeetation  is  that  further 
researeh  will  lead  to  better  and  better  estimators. 

C.  Example  Application  of  Reachability  Analysis 

To  illustrate  the  value  of  the  reaehability  bounds,  let  us 
revisit  the  example  network  defined  in  Seetion  II  where 
nefwork  operalors  were  eonsidering  adding  Iwo  baekup 
links.  Al  a  firsl  glanee,  if  may  seem  lo  be  suffieienl  lo 
reeonfigure  rouling  paramelers  on  fhe  routers  lo  use  fhe 
baekup  links  under  failure  seenarios.  However,  eheeking 
fhe  reaehabilify  bounds  reveals  lhal  sueh  a  design  is  ineor- 
reel.  Speeifieally,  Ihe  fable  below  eompares  Iwo  parlieular 
reaehability  bounds  before  and  after  Ihe  baekup  links  are 
added,  where  ACL{1^  2, 4}  represenls  Ihe  sel  of  paekels 


Before 

After 

Rns 

ACL{1,2,4} 

ACL{1,2,3,4} 

Rh 

ACL{3,2,4} 

ACL{1}U4CL{3,2,4} 

permilled  by  ACL  1,  2  and  4,  and  so  on.  (The  algorilhms 
for  eompuling  Ihese  bounds  are  given  in  Seetion  IV.)  On 
one  hand,  Ihe  lower  bound  from  router  R1  lo  router  R5 
is  furlher  eonslrained  by  Ihe  addition  of  ACL3.  Reeall 
lhal  for  TCP  paekels  wilh  porl  number  1433  (SQL  Iraf- 
lie),  AC  LI  permils  only  Ihose  from  hosls  in  Al  lo  hosls 
in  A5  and  ACL3  permils  only  Ihose  from  A3  lo  A5.  To- 
gelher,  AC  LI  and  ACL‘3  will  deny  all  TCP  paekels  wilh 
porl  number  1433  from  R1  lo  R5  as  Al  and  A3  use  dis- 
linel  address  ranges.  This  defeals  Ihe  purpose  of  adding 
Ihe  new  baekup  links  as  Ihey  will  be  lolally  ineffeelive  for 
SQL  Iraflie  from  R1  lo  R5  under  failure  senarios.  On  Ihe 
olher  hand,  Ihe  upper  bound  from  R3  lo  R5  is  expanded, 
allowing  a  portion  of  mullieasl  Iraflie  lo  spill  oul  of  R3 
againsl  Ihe  seeurily  poliey  eslablished  by  ACTS.  Sinee 
Ihe  baekup  links  are  nol  used  under  normal  eondilions, 
ping  and  traceroute  tools  would  nol  be  of  mueh  help 
in  deleeling  Ihese  problems  wilhoul  deslruelive  lesls  (e.g., 
by  shutting  down  a  primary  palh). 

IV.  Computing  the  Reachability  Bounds 

In  Ihis  seetion,  we  presenl  basie  algorilhms  for  eom- 
puling  Ihe  simple  reaehability  bound  estimators  defined 

®It  is  completely  conceivable  that  a  network  could  have  a  routing 
design  such  that  not  all  paths  can  be  used,  meaning  that  i  and  j  can 
be  effectively  partitioned  even  when  there  are  still  physical  paths  that 
connect  them. 


by  equations  (5)  and  (6).  The  same  algorithms  ean  also 
be  used  to  ealeulate  other  (potentially  tighter)  reaehability 
bound  estimators  as  long  as  the  approximation  is  based 
on  adding  additional  statie  restrietions  to  pre-eonfigured 
paeket  filters.^  Seetion  V  deseribes  sueh  an  approxima¬ 
tion  method. 

We  assume  that  there  are  no  paeket  transformers  in  the 
network.  We  will  relax  this  eondition  in  Seetion  VI. 

Lower  bound  calculation.  To  compute  Rf^^,  we  first 
prune  all  the  edges  <  u,v  >E  E  that  cannot  be  in  any 
path  from  i  to  j.  This  is  accomplished  by  applying  the 
“Articulation  Points  and  Biconnected  Components”  algo¬ 
rithm  for  any  pair  of  i  and  j,  which  is  0{E  +  V)  [1]. 
After  that,  is  simply  the  intersection  of  E^^v  for  t  h® 
remaining  edges. 

Upper  bound  calculation.  While  the  calculation  of 
R^j  is  not  as  straightforward,  we  observe  that  it  closely 
relates  to  the  classical  transitive  closure  algorithm.  Con¬ 
sider  Eu^v  as  describing  the  set  of  packets  that  E^^v  ac¬ 
cepts,  with  empty  set  0  and  the  set  of  all  possible  pack¬ 
ets  denoted  as  $.  Our  labeling  function,  is  a  map 
from  E  to  the  power  set  of  $,  P($),  which  is  closed  un¬ 
der  the  operators  U  and  fl.  It  follows  that  properties  and 
algorithms  in  classical  literature  apply;  in  particular,  so¬ 
lutions  to  compute  transitive  closure  [1]  and  classical  all¬ 
pairs  shortest  paths  algorithms  [6] 

Below  is  a  dynamic  programming  formulation  (as  in 
[1])  for  calculating  Rfj,  with  the  recurrence  relation 
Ri'iJ)"'  =  n  R{k,j)"^-^,  where  R{i,j)"^ 

represents  the  set  of  packets  that  can  go  from  i  to  j  in  up  to 
m  hops.  The  calculation  starts  from  the  destination  router 
j  and  extends  the  path  by  one  hop  with  each  iteration  of 
the  outermost  loop,  and  eventually  taking  all  paths  from  i 
to  j  into  consideration. 

I ! Computing  reachability  upper  bound  matrix  column  j 

1.  Initialize  R{i,j)  to  Ejj  for  all  v, 

2.  for  (m  =  1  to  ||U||  —  2)  do 

3.  for  (?  =  1  to  ||U||)  do 

4.  = 

5.  for  (A:  =  1  to  ||U||)  do 

6.  if  (<  ■?,  k  >e  E) 

then  R'{i,j)  =  R'{iJ)\J{Ei^kr\RikJ)}-, 
1.  R{i,j)=R'{i,j)-, 

Table  II  shows  the  intermediate  results  of  R{i^j)^, 
when  running  the  dynamic  program  on  the  example  net¬ 
work  shown  in  Figure  3.  (This  network  has  a  more  com- 

^Also,  the  upper  bound  algorithm  can  compute  the  instantaneous 
reachability  if  Fu,v(s)  is  known  for  every  edge. 


TABLE  II 

Example  Execution  of  Basic  Algorithm 


m  —  0 

m  =  1 

m  —  2 

m  =  3 

R{t,5) 

0 

0 

6,7 

6,7 

ft(2,5) 

0 

3,4,  6,7 

3, 4,  6,  7 

3, 4,  6,  7 

R{3,5) 

3, 4,  6,  7 

3,4,  6,7 

3, 4,  6,  7 

3, 4,  6,  7 

R{4,5) 

6,7 

3,4,  6,7 

3, 4,  6,  7 

3, 4,  6,  7 

plex  structure  than  the  one  defined  in  Section  II.)  For 
links  with  packet  filters  dehned,  the  figure  shows  fhe  sef 
of  packefs  fhe  filfers  will  pass.  For  simplicify,  packefs  are 
represenfed  by  infegers:  {5  —  8}  refers  fo  packefs  5,6,7, 
and  8.  An  uninsfanfiafed  E^^v  sef  indicafes  a  filfer  fhaf 
passes  all  packefs.  The  desfinafion  roufer  j  is  sef  fo  5. 
The  lasf  column,  when  m  =  3,  gives  fhe  final  resulf  of  fhe 
reachability  from  routers  1-4  fo  roufer  5. 

Algorithm  Complexity.  The  complexity  of  the  illus¬ 
trative  upper  bound  algorithm  above  is  However, 

the  reachability  between  all  pairs  of  routers  can  be  com¬ 
puted  also  in  0{V^)  via  the  same  techniques  used  in  the 
Floyd-Warshall  method  [6]  for  computing  all-pairs  short¬ 
est  paths. 

Our  reachability  analysis  framework  is  targeted  at  com¬ 
puting  the  reachability  for  a  network  operated  and  con¬ 
trolled  by  a  single  organization,  rather  than  the  Internet 
as  a  whole.  As  discussed  earlier,  the  sizes  of  such  net¬ 
works  typically  range  from  5  to  1,000  routers.  With  V 
bounded  like  that,  the  0{V^)  time  complexity  is  very  rea¬ 
sonable.  It  should  also  be  noted  that  the  algorithm  will 
be  run  mainly  as  part  of  a  design  time  tool  installed  on  an 
off-line  system.  In  that  case,  timely  execution  is  not  a  pri¬ 
mary  concern.  For  on-line  troubleshooting,  the  size  of  V 
can  be  reduced  by  refining  the  reachability  analysis  graph 
model  to  incorporate  the  routing  realm  abstraction  so  that 
a  node  in  the  graph  may  represent  a  collection  of  routing 
processes  with  the  same  external  reachability  [10]. 

®It  should  be  noted  that  we  have  made  a  simplifying  assumption  that 
step  6  has  complexity  0(1).  In  real  networks,  Fu,v  is  often  a  nontrivial 
predicate  representation  of  a  set  of  packets.  Performing  set  operations 
over  such  representations  may  incur  higher  cost  than  0(1).  We  are 
currently  investigating  this  issue. 
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V.  Converting  Routing  Information  into 
Packet  Filters 

In  this  section,  we  explain  how  the  effects  of  routing  on 
reachability  can  be  incorporated  into  our  unified  frame¬ 
work  by  adding  additional  terms  to  the  static  packet  filters 
defined  in  roufer  configuration  files.  (We  will  use 
fo  denote  fhe  infersecfion  of  all  packef  fillers  configured 
over  edge  <  rt,  u  >.)  These  lerms  reslricf  fhe  sel  of  pack- 
els  lhal  can  Iravel  from  tt  lo  u  lo  Ihose  packels  lhal  fhe 
nelwork  mighf  route  over  fhe  link  <  >.  The  fol¬ 

lowing  subsections  define  fhe  key  elemenls  in  our  model 
and  Ihen  describe  a  four  step  algorilhm  for  computing  fhe 
addilional  terms  lhal  musl  be  added  lo  The  algo¬ 

rilhm  slarls  wilh  Ihe  routes  lhal  are  explicilly  specified  in 
Ihe  configuration  of  Ihe  nelwork.  Il  Ihen  computes  Ihe 
maximal  sel  of  routes  lhal  could  possibly  end  up  in  each 
router,  subjecl  lo  Ihe  nelwork’s  routing  policies.  Finally, 
il  uses  Ihese  maximal  sels  of  routes  lo  compute  Ihe  addi¬ 
tional  terms. 

We  have  formally  eslablished  lhal  our  algorilhm  com¬ 
putes  a  lighter  estimator  for  Ihe  reachability  upper  bound 
lhan  Ihe  simple  one  defined  by  equation  (5).  The  delails 
are  omilled  here  for  brevity.  Instead,  we  refer  interested 
readers  to  [19],  which  also  discusses  a  limilalion  of  our  al¬ 
gorilhm  in  producing  a  lighl  estimator  for  Ihe  reachability 
lower  bound. 

A.  Definitions  for  Modeling  Routes  and  RIBs 

A  destination  subnel  is  Iradilionally  defined  as  an  ad¬ 
dress  and  nelmask  (Section  II).  However,  we  need  Ihe 
ability  to  reason  aboul  how  routers  will  handle  a  set  of 
destinations.  In  particular,  we  will  need  a  means  to  de¬ 
scribe  Ihe  sel  of  all  possible  destinations.  The  conceplual 
represenlalion  of  Ibis  sel  as  a  lisl  of  all  2^^  possible  IPv4 
destinations  is  unwieldy  to  work  wilh  in  practice,  so  we 
musl  find  a  more  concise  nolalion. 

We  adopl  Ihe  represenlalion  defined  by  Cisco,  where 
a  sel  of  destination  subnels  is  represented  by  a  lisl  of 
{address/nelmask-range}.  For  example,  {128.2/16-24} 
represenls  Ihe  sel  of  all  destinations  whose  firsl  bils  are 
128.2  and  whose  nelmasks  are  from  16  to  24  bils  long; 
{0/0-32}  represenls  Ihe  sel  of  all  possible  IPv4  destina¬ 
tion  subnels;  and  {0/1-32,128/1-32}  represenls  Ihe  sel  of 
all  possible  destinations  wilh  Ihe  defaull  route  {0/0}  re¬ 
moved.  Our  algorilhms  require  lhal  union  and  sublraclion 
be  well  defined  on  Ihese  sels  of  destinations,  and  Ihis  is 
easily  proven.  Where  an  algorilhm  in  Ibis  paper  calls  for  a 
destination  d,  we  can  use  eilher  a  single  destination  subnel 
or  a  sel  of  destination  subnels  interchangeably. 

As  described  in  Section  II,  each  router  conlains  one 
RIB  for  each  routing  process  lhal  il  runs.  A  RIB  rib  is 


conceplually  a  function  rib{d)  lhal  maps  destination  ad¬ 
dress  d  to  a  list  of  “routes.”  A  route  rt  is  a  tuple  with  the 
following  fields  defined: 

•rid  =  set  of  destination  subnets  this  route  applies  to 
•rlinterfaces  =  the  set  of  interfaces  on  the  router  that 
packets  matching  rid  might  be  routed  out 
•rlnextjiop Jp  =  the  set  of  routers  (identified  by  their  IP 
address)  whom  packets  matching  rid  might  be  routed  to¬ 
wards 

•rltype  =  {interface,static}  original  source  of  this  route 
•attributes....  =  a  list  of  key-value  pairs 

The  Router  RIB  (i.e.,  the  routing  table)  of  each  router 
maps  the  complete  IP  address  space  onto  the  set  of  in¬ 
terfaces  according  to  a  longest  prefix  match.  If  there  is 
no  default  route,  all  packets  not  matching  a  more  specific 
route  are  dropped.  We  formalize  the  action  of  the  Router 
RIB  on  router  u  as  Iu{s,d),  which  returns  the  set  of  in¬ 
terfaces  that  packets  to  destination  d  should  be  sent  out 
when  in  forwarding  state  s.^  In  this  paper,  we  only  con¬ 
sider  converged  forwarding  states  —  analysis  of  transient 
states  is  beyond  the  scope  of  this  work.  Previous  works 
have  shown  how  network  configurations  can  be  statically 
checked  to  verify  the  forwarding  state  will  converge. 

For  computing  the  upper  and  lower  bounds  on  reach¬ 
ability,  which  predict  the  network’s  reachability  over  all 
s  E  5,  we  do  not  need  to  compute  Iu{s,d)  but  rather 
the  function  Iu{d)  that  specifies  all  the  interfaces  router  u 
might  potentially  use  to  forward  packets  to  destination  d. 
That  is,  Iu{d)  =  Use5  Iu{s^  d).  Step  2  below  shows  how 
we  calculate  I{d)  by  flooding  routes  through  the  network 
and  identifying  on  each  router  the  interfaces  that  will  be 
candidates  for  carrying  traffic  to  d. 

While  functions  like  I,  D,  and  others  are  router  specific, 
for  brevity  we  will  omit  the  subscript  (e.g.,  using  I{d) 
instead  of  Iu{d))  when  it  is  clear  from  the  context  which 
router  these  functions  are  associated  with. 

B.  Step  1:  Initializing  the  RIBs 

Initially  all  RIBs  are  cleared  of  all  routes.  Then  the  Lo¬ 
cal  RIB  on  each  router  is  populated  with  all  the  routes  that 
are  explicitly  created  on  the  router  by  its  configuration. 
For  each  router  r,  each  interface  ionr  will  be  assigned  a 
subnet  d  by  the  configuration  file:  this  is  represented  by 
setting  LocalRIB(d)  =<  d,  {?},  {r},  type=interface  >. 
Routes  manually  configured  to  direct  packets  to  des¬ 
tination  d  out  interface  i  are  represented  in  the  same 
way.  Static  routes,  which  are  manually  configured  routes 
that  direct  packets  to  destination  d  out  whichever  in¬ 
terface  is  used  to  reach  address  v,  are  represented  as 

®/„(s,d)  usually  maps  d  to  a  single  interface,  but  may  contain  sev¬ 
eral  interfaces  if  Equal  Cost  Multiple  Path  (ECMP)  is  in  use. 
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Fig.  4.  RIB  level  view  of  the  network  illustrating  the  movement  of 
routes  between  RIBs.  Routes,  such  as  ‘til”,  ‘113”,  route  fi  Iters,  such  as 
“+dl,-d3”(“+”as  permit,  “-’’as  deny),  and  fbw  of  routes  according  to 
redistribution  policies  are  shown.  Following  the  route  fbw  diagram, 
we  can  identify  the  origins  of  routes  and  through  which  interfaces  the 
routes  are  imported  or  exported. 

LocalRIB(d)  =<  d,  {},  {i;},  type=static  >.  The  outgo¬ 
ing  interface  for  a  static  route  is  determined  in  Step  3  us¬ 
ing  a  recursive  lookup. 

If  we  are  computing  the  reachability  upper  bound,  the 
RIBs  of  all  routers  external  to  the  network  are  populated 
with  a  single  route  with  destination  {0/0-32}  —  the  set 
of  all  possible  destinations.  This  is  a  conservative  ap¬ 
proximation  consistent  with  computing  the  upper  bound 
on  reachability,  since  whatever  destinations  the  peer  does 
advertise  will  be  covered  by  {0/0-32}. 

If  we  are  computing  the  lower  bound  on  reachability, 
the  RIBs  of  all  routers  external  to  the  network  are  left 
empty.  This  conservative  approximation  is  consistent  with 
computing  the  lower  bound  on  reachability,  since  in  the 
worst  case  the  external  routers  will  export  no  routes  what¬ 
soever  to  our  routers,  perhaps  due  to  misconfiguration, 
bugs,  crashes,  etc. 

If  the  routes  the  external  peers  are  expected  to  export 
are  known,  the  RIBs  in  our  model  can  be  initialized  ac¬ 
cordingly  and  the  bounds  computed  on  reachability  will 
be  correspondingly  tighter. 

C.  Step  2:  Computing  the  Potential  Set  of  Routes 

In  this  step,  we  compute  the  set  of  routes  that  could 
potentially  occupy  each  RIB  by  flooding  routes  from  the 
local  RIBs  and  external  RIBs  throughout  the  network. 
The  flooding  process  is  governed  by  the  routing  policies 
between  adjacent  RIBs  that  determine  which  routes  are 
passed,  modified,  or  dropped.  At  the  end  of  the  step,  we 
will  have  calculated  for  each  RIB  rib  the  maximal  set  of 
routes  that  rib  could  potentially  hold  and  V{rib),  the  set 
of  destinations  that  rib  covers. 

As  illustrated  in  Figure  4,  the  routing  design  of  a  net¬ 
work  forms  a  graph  Grib  =  (^rib,  -Erib,  P),  where  Vrib 


is  the  set  of  RIBs  in  the  network  and  F?rib  describes 
the  adjacencies  between  RIBs  over  which  routes  are  im¬ 
ported,  exported,  and  redistributed.  V  is  the  set  of  routing 
policies  that  govern  how  routes  move  between  RIBs,  i.e., 
for  <  x^y  >E  F^rib,  the  policy  Px^y  £  V  determines 
which  routes  can  move  from  RIB  x  to  RIB  y.  Unlike 
packet  filters  in  T,  routing  policies  in  V  can  transform 
the  routes  they  are  applied  to  by  changing  the  route’s  at¬ 
tributes. 

Note  that  graph  Grib  may  be  partitioned  and  that  adja¬ 
cencies  among  RIBs  need  not  follow  the  physical  links  of 
the  network.  That  is,  the  edge  set  of  the  RIB  graph  F?rib 
can  be  different  from  the  edge  set  E  of  the  physical  graph 
G  in  Section  III.  For  example,  there  is  a  physical  link  be¬ 
tween  routers  1  and  5  in  Figure  4,  but  no  RIB  adjacency 
traverses  it,  or,  in  the  case  of  networks  using  internal  BGP 
(IBGP),  a  single  edge  in  Grib  representing  an  IBGP  adja¬ 
cency  may  traverse  multiple  physical  links. 

We  first  define  a  helper  function  push(r?6,  rf)  that 
takes  route  rt  found  in  rib  and  pushes  it  into  all  the  ad¬ 
jacent  RIBs.  Lines  2-5  prepare  a  candidate  route  for  entry 
into  the  adjacent  RIB.  Line  6  applies  the  routing  policy 
governing  which  routes  can  be  pushed  into  the  adjacent 
RIB,  potentially  altering  or  dropping  the  route  in  the  pro¬ 
cess.  Lines  7-8  add  the  candidate  route  into  the  adjacent 
RIB. 

push  (RIB  a;,Route  rt)  = 

1.  Forall  <  x,y  >E  F?rib 

2.  r  =  router  on  which  RIB  x  resides 

3.  V  =  router  on  which  RIB  y  resides 

4.  rlinterfaces  =  {interfaces  on  v  where 

edge  <  x,y  >  could  arrive} 

5.  rlnextJiop  jp  =  r 

6.  rt'  =  Px,y{rt) 

1.  y{rt'A)  =  y(rf'.d)  [jrt' 

8.  V{y)=V{y)\Jrt'.d 

Using  push(r?6,  rt),  we  compute  rib  for  each  RIB  on 
each  router  by  iterative  relaxation:  applying  push()  to 
each  route  in  each  RIB  until  there  are  no  changes  in  the 
contents  of  any  RIB. 

Much  of  the  work  in  modeling  routing  lies  with  the  pol¬ 
icy  Px,y{rt)  in  step  6.  However,  these  expressions  can  be 
directly  extracted  by  parsing  the  description  of  the  net¬ 
work  (e.g.,  the  router  configuration  files).  Px^y  must  im¬ 
plement  the  export  policy  of  RIB  x  and  the  import  pol¬ 
icy  of  y,  but  has  tremendous  flexibility  given  its  ability  to 
modify  the  routes  it  is  applied  to.  Typical  policies  seen  in 
real  networks  include: 

-  A  policy  that  passes  routes  to  destination  subnets  1/8 
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and  128.2/16  and  drops  all  other  routes. 

Px,y{rt)  =  r/'.d  =  r/.d- {1/8 -8, 128.2/16 -16} 
if  r^^d  ^  0  then  return  rt'  else  0 

-  A  poliey  that  governs  the  EBGP  adjaeeney  between 
ASl  and  AS2,  where  all  routes  are  passed,  but  ASl  must 
prepend  its  AS  number  to  the  route’s  AS  path. 

Px,y{ft)  =  r/.as_path  =  eoneatenate(AS'l,  r/.as_path) 

-  A  poliey  that  governs  the  EBGP  adjaeeney  between 
ASl  and  AS2,  where  routes  whose  AS  path  matehes  a 
regular  expression  looking  for  AS3  are  dropped. 


Case  1  handles  the  base  ease  of  a  simple  route  that  for¬ 
wards  paekets  out  a  speeifie  interfaee.  Case  2  handles 
statie  routes,  whieh  require  a  reeursive  lookup  to  deter¬ 
mine  whieh  interfaees  are  used  to  reaeh  the  next-hop  spee- 
ified  in  the  route.  Case  3  handles  BGP  sessions,  whieh  are 
earried  in  TCP  session  that  ean  traverse  multiple  routers. 
A  reeursive  lookup  for  the  address  at  the  other  end  of  the 
session  is  required  to  determine  whieh  interfaees  the  TCP 
session  might  arrive  on,  and  thus  what  outgoing  interfaees 
might  be  used  for  routes  learned  from  that  session.^  Case 
4  handles  all  other  routing  protoeols,  where  the  poten¬ 
tial  outgoing  interfaees  are  those  leading  to  the  neighbor 
routers  from  whieh  the  router  imported  route  d. 


Px,y{f’t)  =  rf'.as_path  =  rf.as_path  —  /AS3/ 

if  rlas_path  7^  0  then  return  rt'  else  0 

The  time  eomplexity  of  this  step  is  0(|  Vrib  |  x  /  x  |rf|  x 
2ax/j  where  I  is  the  length  of  the  longest  eyele  in  the 
graph  Grib  and  |r/|  is  the  number  of  initial  routes.  The 
20  X/  results  from  the  potential  need  to  split  a  route 
into  multiple  routes  eaeh  time  it  is  pushed,  where  a  is  the 
fraetion  of  polieies  that  require  splitting  routes.  Prom  our 
experienee  so  far,  a  is  small  for  real  networks. 


D.  Step  3:  Computing  I  (d)  for  each  router 

Reeall  that  I  (d)  is  a  router  speeifie  funetion  that  returns 
the  set  of  interfaees  out  whieh  the  eorresponding  router 
might  forward  a  paeket  destined  to  d.  To  ealeulate  I{d) 
for  a  router,  we  go  through  all  the  RIBs  on  that  router 
looking  for  routes  that  eover  d,  and  then  union  together  the 
interfaees  for  those  routes.  I (d)  is  defined  reeursively,  and 
fhe  base  eases  are  generally  routes  found  in  fhe  Eoeal  RIB. 
Por  readabilify,  we  infroduee  a  helper  funelion  ifs(rf,  rib) 
fhaf  eompufes  fhe  interfaees  fo  whieh  roufe  rt  in  rib  mighf 
direcf  paekefs. 


m  =  u  ifs(rf,  rib),  where  rt  =  rib{d) 

rib:  dEVlrib) 


\fs{rt,  &)  =  < 


r/.inlerfaees  if  6  is  a  LocalRIB,  and 

rt.type  =  interface; 

UdGrt  .next_hop_ips  i{d)  if  6  is  a  LocalRIB,  and 
rt.type  =  static; 

Udert.next.hop.ips  b  is  a  BGP-RIB; 


rf.  interfaees 


otherwise. 


E.  Step  4:  Computing  Packet  Filters  that  Represent  the 
Effects  of  Routing 

With  I{d)  in  hand,  we  know  the  set  of  interfaees  out 
whieh  paekets  destined  to  d  might  be  sent.  We  first  eom- 
pute  the  inverse  mapping  of  I (d),  D{i),  whieh  returns  the 
set  of  destination  subnets  that  potentially  map  to  interfaee 
i,  i.e.,  D{i)  =  {d  \  i  E  I{d)}.  Using  D{i)  we  map  the 
routing  table  information  to  paeket  filters  as  follows: 

Pet  r  denote  the  router  under  eonsideration.  Por  all  in¬ 
terfaees  i  onr  and  for  all  routers  v  that  are  direetly  eon- 
neeted  to  r  via  interfaee  i,  add  the  following  elauses  to 
Pr,v 

=  Fr,v  n  {p  I  p.dst_addr  E  D{i)}  (7) 

This  filter  will  pass  any  paeket  going  to  a  destination 
that  r  might  possibly  route  out  the  link  to  v,  and  drop  all 
the  paekets  that  r  would  never  route  via  v. 

VI.  Handling  Packet  Transforms 

In  this  seetion,  we  refine  fhe  basie  algorilhm  presenled 
in  Seelion  IV  so  lhal  if  will  work  wilh  nelworks  fhaf  in- 
elude  paekel  Iransforming  fillers.^ 

We  have  found  lhal  Ibis  refinemenl  ean  be  aeeom- 
plished  wilhoul  ehanging  fhe  fundamenlal  slruelure  of 
fhe  basie  algorilhm.  Speeifieally,  we  separate  fhe  paekel 
Iransforming  parls  from  fhese  fillers  and  infroduee  virlual 

^In  IBGP  it  is  possible  to  explicitly  set  a  ‘third-party”  next-hop,  but 
this  is  unusual.  If  we  see  the  confi  guration  commands  for  this,  we  set 
I{d)  to  be  all  interfaces  on  the  router  for  all  d  potentially  learned  over 
this  session. 

®For  networks  containing  packet  transformers,  the  set  of  packets  that 
a  destination  can  receive  may  be  different  than  the  set  a  source  can  send 
to  that  destination.  For  this  paper,  we  calculate  reachability  as  the  set 
of  packets  the  source  can  send,  although  our  results  can  be  extended  to 
also  calculate  a  set  describing  what  those  packets  might  look  like  on 
arrival  at  the  destination. 
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(Case  2) 


Fig.  5.  Explicitly  modeling  packet  transformations  using  f,,,  and  a 
virtual  node. 

components  to  represent  them  explicitly  in  the  reachabil¬ 
ity  analysis  graph  G.  This  is  illustrated  in  Figure  5.  There 
are  two  cases:  (1)  the  packet  transformation  t  is  applied 
after  the  packet  filtering  (e.g.,  ToS  remarking),  and  (2)  the 
transformation  t  is  applied  before  the  packet  filtering  (e.g., 
NAT).  In  ether  case,  a  virtual  node-edge  pair  is  introduced 
to  model  the  separate  processing  stage.  Each  virtual  edge 
is  labeled  with  a  t  function  representing  a  packet  trans¬ 
form. 

We  have  discovered  that  packet  transforms  may  have 
two  undesirable  properties  that  can  complicate  the  reacha¬ 
bility  analysis.  First,  a  transform  might  not  be  one-to-one. 
For  example,  in  the  case  of  ToS  remarking,  multiple  ToS 
values  may  be  mapped  into  one  single  ToS  value.  Also, 
in  the  case  of  NAT,  one  external  address  pool  is  typically 
reused  for  many  hosts  as  long  as  no  two  hosts  use  the  same 
external  address  and  port  number  at  the  same  time. 

Second,  a  transform  may  not  even  be  a  deterministic 
function.  In  some  modes  of  NAT,  a  packet  is  not  always 
transformed  into  the  same  packet;  the  source  address  the 
packet  gets  depends  on  the  current  availability  of  the  ad¬ 
dress  pool.  To  address  these  problems,  we  define  a  gen¬ 
eralized  inverse  function  of  t,  over  an  arbifrary  packef  sef 
F,  as:  t~^{F)  =  I  ^  ^  which  refurns  fhe 

sef  of  all  possible  packefs  fhaf  can  be  Iransformed  using  t 
fo  a  packef  in  F. 

Using  fhe  inverse  fransform  funcfion,  we  have  refined 
fhe  basic  algorifhm  fo  handle  packef  fransforms.  Specifi¬ 
cally,  only  steps  1  and  6  of  fhe  original  algorifhm  need  fo 
be  changed. 

I’For  all  i,  initialize  R{i-,j)  as  follows: 
fo  Fij,  if  <  j  >  is  filter 
fo  sef  of  all  packefs,  if  <  f ,  j  >  is  fransformer 
fo  0,  if  <  i,j  E 

6\  if  {<i,k  >E  E  and  <  f,  fc  >  is  fransformer) 

then  R'{i,j)  =  R'{i,j)\Jt^l{R{k,j)); 
else  if  (<  i,  k  >E  E  and  <  i,k  >  is  filter) 


then  i?'(f,j)  =  R'{iJ)  j)}; 

The  intuition  behind  the  new  clause  in  6’  is  that  if  the 
set  of  packets  described  by  can  reach  from  k  to 

j,  then  only  those  packets  arriving  at  i  that  transforms 
into  a  packet  in  the  set  j)  will  be  able  to  reach  from 
i  to  j.  To  find  this  set  of  packets  that  t  will  transform  into 
R{k,j),  we  calculate  tE^{R{k,j)). 

The  complexity  of  the  new  algorithm  is  still  0{V^). 
It  should  be  noted  that  the  algorithm  requires  two  addi¬ 
tional  elements  to  be  complete:  (i)  an  efficient  method  to 
compute  the  inverse  function,  and  (ii)  a  condition  to  throw 
out  paths  with  loops  because  a  looping  path  containing  a 
packet  transform  edge  may  alter  the  outcome.  Fuckily, 
the  inverse  function  for  commonly  used  transforms,  such 
as  NAT  and  ToS  remarking,  are  very  simple  —  though  in 
general  the  inverse  of  other  transforms  may  be  more  com¬ 
plicated.  For  brevity,  the  details  of  (ii)  are  omitted. 

Fet’s  revisit  the  example  network  in  Figure  3  to  illus¬ 
trate  the  steps  of  the  refined  algorithm.  Suppose  node  1 
now  uses  a  leading  packet  transform:  {1,2}  {5,6}, 

meaning  that  packets  1  and  2  each  will  be  mapped  into 
either  packet  5  or  6  before  processed  by  node  I’s  packet 
filter.  The  new  reachability  analysis  graph  becomes  Fig¬ 
ure  6  and  the  execution  steps  of  the  refined  algorithm  are 
shown  in  Table  III.  At  the  last  step  (m  =  4),  i?(l,5)  is 
changed  due  to  the  transform. 

Our  framework  currently  requires  that  packet  trans¬ 
forms  be  maps  over  sets  of  packets.  They  cannot  test 
a  property  of  a  packet  and  behave  one  way  if  the  prop¬ 
erty  is  true  and  another  way  if  the  property  is  false.  In 
particular,  some  networks  include  functionality  called  a 
“stateful  firewall”.  These  are  like  a  NAT,  but  only  cre¬ 
ate  the  mapping  when  a  packet  traverses  from  the  inside 
of  the  firewall  to  the  outside.  Since  our  framework  cur¬ 
rently  has  no  notion  of  whether  a  packet  has  already  been 
sent  through  the  stateful  firewall  from  inside  to  outside, 
we  cannot  directly  model  the  reachability  the  stateful  fire¬ 
wall  provides.  However,  we  can  calculate  the  reachabil¬ 
ity  assuming  a  packet  has  traversed  the  firewall,  in  which 
case  the  firewall  functions  as  a  NAT  described  above,  and 
again  assuming  no  packet  has  traversed  it,  in  which  case 
the  firewall  functions  as  a  block. 
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TABLE  III 

Example  Execution  oe  Refined  Algorithm 


m  —  Q 

m—1 

m  —  2 

m  —  3 

m  =  4 

R(l,5) 

0 

0 

6,7 

6,7 

1,2,  6,  7 

R(2,5) 

0 

3,  4,  6,  7 

3, 4,  6,  7 

3, 4,  6,  7 

3,  4,  6,  7 

R(3,5) 

3,4,  6,7 

3,  4,  6,  7 

3, 4,  6,  7 

3, 4,  6,  7 

3,  4,  6,  7 

R(4,5) 

6,7 

3,  4,  6,  7 

3, 4,  6,  7 

3, 4,  6,  7 

3,  4,  6,  7 

VII.  Reachability  Analysis  in  Larger 
Context 

In  this  section,  we  describe  how  static  reachability  anal¬ 
ysis  relates  to  our  larger  goal  of  understanding  and  im¬ 
proving  the  design  of  IP  networks  and  routing  policies. 
We  also  discuss  the  limitations  of  static  analysis  and  how 
to  move  beyond  them. 

A.  Understanding  and  Improving  Routing  Design 

Our  work  on  static  reachability  analysis  contributes  to 
our  broader  research  agenda  of  improving  routing  design 
and  network  robustness.  Today,  routing  design  is  largely  a 
complex  “art”  mastered  by  an  increasingly  overwhelmed 
community  of  highly-skilled  human  operators.  We  aim  to 
uncover  the  fundamental  abstractions,  such  as  the  reach¬ 
ability  bounds  R^j  and  Rfj,  that  can  be  used  to  validate, 
evaluate,  and  even  generate  the  routing  design  for  a  net¬ 
work.  Our  analysis  framework  opens  several  avenues  for 
ongoing  work: 

Verification  of  network  design  goals:  A  network  has 
some  (explicit  or  implicit)  design  goals  for  providing 
reachability  between  certain  parties  under  certain  condi¬ 
tions.  For  example,  a  network  may  need  to  ensure  that 
two  business  competitors  (customers  A  and  B)  can  never 
reach  each  other  under  any  circumstances.  This  property 
can  be  checked  directly  by  ensuring  that  Rf^  is  empty  for 
all  i  in  customer  A’s  network  and  j  in  B’s  network,  and 
vice  versa.  Alternatively,  a  network  may  need  to  ensure 
that  a  customer  can  reach  a  data  center;  this  can  be  as¬ 
sured  by  analyzing  the  lower  bound  on  reachability.  Re¬ 
peating  the  reachability  analysis  on  the  subgraphs  formed 
after  link  and  node  deletions  can  test  that  network  reacha¬ 
bility  persists  under  certain  failure  modes. 

Design  patterns  and  best  common  practices:  The 
same  reachability  goals  can  be  satisfied  by  a  wide  variety 
of  different  routing  designs.  Our  concise  representation 
of  reachability  provides  an  appealing  way  to  characterize 
and  compare  routing  designs  and  identify  common  ways 
of  configuring  a  nefwork  to  satisfy  the  goals.  Using  router 
configuration  data  for  several  networks,  we  plan  to  iden¬ 
tify  common  kinds  of  reachability  goals  and  the  combi¬ 
nations  of  routing  protocols,  routing  policies,  and  packet 


filters  used  to  achieve  them.  We  also  plan  to  explore  the 
trade-offs  between  using  routing  policies  and  packet  fil¬ 
ters  in  constraining  reachability,  and  create  guidelines  for 
selecting  one  mechanism  over  the  other.  In  particular,  we 
hope  to  understand  the  motivations  for  applying  packet  fil¬ 
ters  in  the  interior  of  routing  domains,  rather  than  simply 
at  the  periphery. 

Influence  of  dynamic  routing  information:  Our  up¬ 
per  and  lower  bounds  (Rj^  and  define  an  “envelope” 
thaf  constrains  the  influence  of  dynamic  information,  such 
as  topology  changes  or  routes  learned  from  neighboring 
domains,  on  network  reachability.  We  plan  to  analyze 
existing  networks  in  terms  of  the  range  between  the  up¬ 
per  and  lower  bounds.  The  gap  between  the  upper  and 
lower  bounds  may  reflect  the  purpose  of  the  network — 
to  provide  broad  reachability  for  many  client  domains  to 
the  entire  Internet  or  to  to  provide  narrow  reachability  for 
client  domains  to  specific  network  services.  Alternatively, 
a  wide  range  might  imply  the  need  for  more  protective 
packet  and  route  filtering,  whereas  a  narrow  range  may 
overly  constrain  the  ability  of  the  network  to  adapt  to  dy¬ 
namic  changes. 

For  each  of  these  avenues  for  future  work,  our  reacha¬ 
bility  analysis  offers  a  general  and  concise  way  to  analyze 
and  compare  routing  designs  at  a  level  of  abstraction  well 
above  the  low-level  details  of  router  configuration  com¬ 
mands  and  specific  routing  protocols. 

B.  Moving  Beyond  Static  Analysis 

Although  static  analysis  provides  significant  insights, 
dynamic  information  determines  where  a  network  actu¬ 
ally  operates  in  the  space  between  the  lower  and  upper 
bounds  on  reachability.  Our  static  analysis  can  be  ex¬ 
tended  by  incorporating  measurements  of  the  dynamic 
state  of  the  network  and  the  routes  learned  from  neigh¬ 
boring  domains: 

Dynamic  network  state:  The  configuration  state  de¬ 
fines  fhe  IP  links  and  routing  protocol  adjacencies  that 
could  exist,  without  indicating  whether  they  do  exist  at 
any  given  time.  Various  kinds  of  measurement  data  can 
provide  the  missing  information.  The  up/down  status  of 
links  and  sessions  can  be  tracked  via  the  Simple  Network 
Management  Protocol  (SNMP)  or  vendor-specific  “sys- 
log”  data.  In  addition,  a  routing  monitor  [14]  can  contin¬ 
uously  track  the  topology  (routers  and  links)  and  config¬ 
urable  parameters  (e.g.,  OSPF  link  weights)  within  each 
routing  instance. 

Routing  information  from  neighbors:  Similarly, 
static  analysis  considers  the  route  advertisements  that 
could  come  across  links  and  sessions  to  neighboring  do¬ 
mains,  rather  than  the  ones  that  are  available  at  any  given 
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time.  The  set  of  routes  announeed  by  a  neighboring  do¬ 
main  eould  be  gleaned  through  route  monitoring  or  peri- 
odie  dumps  of  the  Routing  Information  Base  (RIB)  at  the 
edge  routers.  In  addition  to  identifying  whieh  prefixes  are 
advertised,  the  RIB  data  would  identify  the  route  attributes 
(sueh  as  AS  path  in  BGP)  that  might  affeet  how  the  reeeiv- 
ing  router  modifies  or  seleefs  roufes.  In  addifion,  fhe  RIB 
would  indieafe  whefher  fhe  neighbor  adverfises  subnefs  of 
a  given  prefix  fhaf  would  have  preferenee  over  fhe  super- 
nef  in  “longesf  prefix  mafeh”  forwarding  of  IP  paekefs. 

VIII.  Related  Work 

Many  “ping”  and  “fraeeroufe”  fools  have  been  de¬ 
veloped  fo  help  froubleshoof  reaehabilify  problems  in  a 
live  nefwork.  However,  fhey  are  limifed  fo  fhe  eheek- 
ing  fhe  insfanfaneous  reaehabilify  for  fhe  parfieular  fype 
of  probe  paekefs  fhey  generafe.  There  has  been  signifi- 
eanf  progress  [18],  [12],  [5]  in  undersfanding  fhe  behav¬ 
ior  of  operating  nefworks  by  measuring  fhe  routing  pro- 
foeols  and  esfablishing  fhe  roof  eause  of  ehanges.  Our 
approaeh  does  nol  affempf  fo  deseribe  fhe  defailed  behav¬ 
ior  of  fhe  roufing  profoeols,  and  if  applies  fo  paekef  fillers 
and  paekef  fransformalion  as  well  as  routing. 

Bush  and  Griffin  [2]  formulale  and  derive  suffieienl 
eondifions  for  fhe  eonneefivify  (reaehabilify)  eonslrainls 
of  Virlual  Privale  Rouled  Nefworks  (VPRNs).  Our  work 
is  eomplemenlary,  bul  broader  in  seope  in  lhal  we  frame 
and  laekle  fhe  general  problem  of  reaehabilify. 

IX.  Conclusions 

This  paper  rigorously  formulafes  fhe  ehallenging  prob¬ 
lem  of  eompufing  fhe  reaehabilify  an  IP  nefwork  provides 
and  deseribes  a  framework  lhal  ean  be  used  fo  ealeulale  if. 

The  framework  provides  a  unified  way  for  joinlly  rea¬ 
soning  aboul  fhe  effeels  fhe  Ihree  very  differenl  meeha- 
nisms  of  paekef  fillers,  roufing  poliey,  and  paekef  Irans- 
formalions  have  on  fhe  nelwork’s  reaehabilify. 

Finally,  we  show  how  fhe  framework  ean  be  applied  fo 
a  slalie  deseriplion  of  fhe  nelwork’s  definition,  allowing 
if  fo  be  applied  eilher  during  fhe  nefwork  design  proeess 
or  fo  a  deployed  nefwork.  Our  leehnique  for  slalie  anal¬ 
ysis  of  nefwork  reaehabilify  is  valuable  for  verifying  fhe 
inlenl  of  fhe  nefwork  designer,  Iroubleshooling  reaehabil- 
ily  problems,  and  performing  “whal-if”  analysis  of  failure 
seenarios. 

Now  lhal  we  have  Ihis  formal  framework,  our  fulure 
work  is  foeused  on  experimenlal  evaluation  of  fhe  algo- 
rilhms  on  a  sel  of  nefworks.  For  example,  our  frame¬ 
work  ean  be  exfended  for  eompufing  finer-grain  reaeha- 
bilily  bounds,  sueh  as  ones  lhal  eonsider  only  a  subsel  of 
paekefs  (e.g.,  Ihose  earrying  TCP  porl  1443  Iraffie)  or  a 
subsel  of  palhs  (e.g.,  exeluding  eerlain  links). 
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